A list of acronyms is reported in APPENDIX 1.
FIG. 1a reports the general diagram of an UMTS system constituting the preferred but not exclusive environment for the application of the present invention. The description will be provided for an UMTS FDD and TDD system, where the claimed method well fits due to the specific network architecture, but it can be easily extended to other kind of cellular networks like for instance GSM which makes use of a similar network architecture.
UMTS of FIG. 1a comprises a Core Network 1 (see TS 23.002) connected to an UTRAN (see TS 25.401), in its turn connected via radio to several mobile user equipments UEs. UTRAN and its served UEs constitute a RNS (see TS 23.110). UTRAN includes a certain number of Radio Network Controllers RNC of the type 2 and 3, each connected to a respective cluster of so-called Node B blocks 4, 5 and 6, 7 interfaced to the UEs. As known, all PLMNs are deployed on a territory subdivided into contiguous service cells, each corresponding to the radio coverage area of a fixed base station. One or more cells compose a Node B. The two RNCs 2 and 3 are connected: to each other by the Iur interface, to the NodeBs 4 to 7 by means of as many lub interfaces, and to the Core Network 1 through the Iu interface. NodeBs and the UEs are connected to each other through the Uu radio interface. Transmissions on the Uu interface are based on a CDMA technique which implies that multiple signals can be transmitted in the same time interval and in the same frequency band, but separated in the code domain. Depending on the adopted standard, the CDMA transmissions can be further based on TDMA technique. The TDMA technique implies that each frame is subdivided in a fixed number of timeslots, each of them conveying one or more CDMA bursts, and different timeslots of the frame can be assigned to different users or alternatively to pilots a common signalling channel.
With reference to the exemplary network architecture described in FIG. 1b, the core network CN includes a CIRCUIT SWITCHED part and a PACKET SWITCHED part. The first one is connected to the PSTN (Public Switched Telephone Network) while the second one is connected to the IP (Internet Protocol) network. The circuit switched part includes the MSCNVLR network elements which together allow wandering of users inside the territory covered by the network. The packet switched part includes two network elements known as SGSN and GGSN. The first one is interfaced to the MSCJVLR and to the HLR to catch location information of the UEs in the packet switched domain. The S-RNC is interfaced to the MSCNVLR block through the Iu(CS) interface and to the SGSN node through the Iu(PS) interface. The SGSN node is further interfaced to the GGSN node through the Gn interface. The GGSN node is further interfaced to the IP network through the Gi interface.
As far as the operation is concerned, the RNC is responsible of the Layer 2 (RLC, MAC) and Layer 3 (RRC) protocol stacks, as well as of the requested line protocols for interfacing the Core Network and the controlled NodeBs. The NodeB is responsible of Layer 1 as well as of the requested line protocols for interfacing the UEs and the RNC. Contrary to GSM, in a UMTS system a radio connection between the UE and the radio access network can make use of more than one radio link; the totality of the radio links constitutes the so called “Active set” and the functionality they allow is the so called “macro diversity” also useful for “Soft handover”. Macro diversity permits the UE to exploit reception from multiple links, combing all the received signals in the most efficient way. During the course of the connection, the number of cells composing the active set can be changed, that is some cells can be removed and some others can be added, following the UE mobility. As an example, FIG. 2 depicts the case of a UE initially connected to Cell A, so having an active set composed by one cell (Cell A) only; then adding Cell B, therefore with two cells (Cell A and Cell B) in the active set, and finally replacing Cell A with Cell C, so again with two cells (Cell A and Cell C) in the active set. In the case that Cell A is connected to a first RNC, and Cell B and Cell C to a second RNC, it comes out that at the end the UE is only connected to Cell A and Cell C, indirectly managed by the first RNC. This case of course applies if no RNC relocation happened in between; i.e. if the management of the connection is not transferred from the first RNC to the second RNC, operation which actually does not happen frequently.
Though multiple cells, and possibly also multiple NodeBs, only one RNC controls, maintains and terminates the control of a radio connection. The controlling RNC is named Serving RNC (S-RNC) whereas the other involved RNCs are named Drift RNCs (D-RNC). The D-RNC is responsible for managing the resources of the directly controlled NodeB(s) and to transfer the information between these NodeBs and the S-RNC. The D-RNC communicates with the S-RNC over the Iur interface. S-RNC decides to add, remove or replace radio links from the active set, and terminates the call towards the core network. FIG. 3 represents an application of the example of FIG. 2 to the UTRAN of FIG. 1a, where RNC 2 plays the role of S-RNC whereas RNC 3 the role of D-RNC. In the scenario of FIG. 3 the connections and interfaces of the active set are indicated by thick lines.
3GPP, the 3rd Generation Partnership Project, is responsible for standardising UMTS FDD and TDD radio access networks. 3GPP TS 25.423: “Technical Specification Group Radio Access Network; UTRAN Iur Interface RNSAP Signalling” has defined the messages exchanged over the Iur between the S-RNC and the D-RNC for adding or deleting radio links; these Layer 3 messages are in accordance with the protocol RNSAP. RNSAP supports basic inter-RNC mobility and Dedicated Channel (DCH) traffic, as well as Common Channel (CCH) traffic transmission.
Generally, all radio access networks collect traffic data, which allow an operator to monitor the offered service quality and possibly take the appropriate countermeasures when this is judged to be not as good as expected. Such data collection is done by the so called Performance Measurement (PM) counters, i.e. by counters of specific traffic events such as:                Number of radio access attempts;        Number of radio access successes;        Number of radio link failures;        Number of Handover attempts, and so on.        
The report of a specific event can also be done with reference to a specific cause, e.g. number of radio access attempts “for signalling connection” or “for Packet call” or “for Circuit switched call”, etc. Data collected by a PM counter can highlight problems or inefficiencies in the network which cannot be visible otherwise. A hardware fault can be immediately signalled by the specific alarm, when foreseen, but e.g. a software bug or a suboptimum cell planning do not end up in a clear alarm notification. Here, only after collecting a consistent amount of traffic data and performing some post elaboration, a sensible conclusion can be drawn. Now, PM counters are actually collectors of traffic events which allow such post elaboration. Therefore, for such kind of problems, they remain the only effective instruments at the hands of the operator for controlling his network. However, for a PM counter being effective, it is important that it does not only report the numerousness of a given event, but also the information of where the collected data have been taken. This is particularly true for PM counters collecting radio link failure events, that is the numerousness of those events which caused the release of a radio link and possibly the drop of the call. For these cases, it is very important for the operator to know the affected cells in order to start the investigation and eventually intervene as appropriate.
In general, the more precise the provided geographical information is, the more the memory requirements are at the network element collecting the traffic data. In the case of PM counters collecting radio link failure events, due to the huge amount of recording memory required, providing this geographical information is not easily affordable with the actual standardization, with the consequence that generally the effectiveness of the reported data is drastically reduced. The problem arises from the interaction between the mechanism foreseen to count radio link failure events which end up with the release of the radio connection. In fact, it is important to observe that the deletion of a radio link does not necessarily end up with the release of the radio connection: e.g. a radio link can be part of an active set counting more radio links or can be replaced by another radio link offering better receive characteristics. However, D-RNC has no means to conclude whether the radio connection will continue to be active after the radio link deletion or will be released.
The next FIGS. 4, 5, and 6 reproduced by TS 25.423 help us to understand this fact. FIG. 4 shows the Radio Link Deletion procedure over the Iur interface of FIG. 3 in case of successful case. With reference to FIG. 4, the S-RNC sends a RNSAP Radio_Link_Deletion_Request message to the D-RNC, which firstly successfully completes the deletion of the radio link existing between the UE and Cell C and then sends back a Radio_Link_Deletion_Response message to the S-RNC. The radio link existing between the UE and Cell C is directly deleted by the S-RNC. FIG. 5 shows the content of the RNSAP “Radio_Link_Deletion_Request” message, while FIG. 6 shows the content of the “Radio_Link_Deletion_Response” message. With reference to FIG. 5, the meaning of the various voices of the IE/Group Name is listed below:                The Message Type uniquely identifies the message being sent.        The Transaction ID is used to associate all the messages belonging to the same procedure. Messages belonging to the same procedure shall use the same Transaction ID. This ID is determined by the initiating peer of a procedure.        The RL ID is the unique Identifier (ID) for one RL associated to a UE.        
As shown in FIG. 5, the Radio_Link_Deletion_Request message sent by the S-RNC contains no indication to the D-RNC as to whether the radio connection will continue to be active after the radio link deletion or will be released. The conclusion is that only the S-RNC is currently able to count the number of radio connection release events following the removal of a radio link. Now, as explained above, removal of a radio link can be triggered by a bad received quality, e.g. the lost of synchronisation to that radio link at the receiving NodeB. Loss of uplink synchronisation which ends up with a release of a radio connection, is considered as an abnormal event which should be avoided as much as possible. Its occurrence can reveal a lack of radio coverage or the presence of an unexpected interference which needs to be solved out by the operator. But as explained above, in order for an operator to take the appropriate remedy in front of a big number of radio connection releases due to a radio link failure cause, it is imperative to know the cell identity where such big number of failure events occurred. In order to provide the needed geographical information together with the collected data, the S-RNC should store as much PM counters for connection release events due to a radio link failure as the number of directly controlled cells, i.e. cells belonging to NodeBs connected to the S-RNC via lub, as well as possibly indirectly controlled cells, i.e. cells belonging to NodeBs connected to the S-RNC via Iur. While storing the cell identity of the directly controlled cells is feasible and generally done, this is not the case for the other cells, fundamentally because their number can be very big. To provide some figures: in average, the number of cells which are directly managed by an RNC can be of the order of 1000, And RNC can usually have up to 8 Iur connections with different RNCs, therefore it comes out that recording cell context of the neighbour RNCs would increase the number of PM counters from 1000 to 8000. This is surely a cumbersome and very expensive task to carry out indeed, also considering that a lot of additional information fields other then the pure counting are associated to each PM counter for connection release events due to a radio link failure.
Three known ways at least have been proposed to partially remedy to this issue; they are illustrated in the following. A first one consists to provide the S-RNC with a basket PM counter which is incremented every time a connection is abnormally released due to that the D-RNC is reporting back notice of a radio link failure detected in one of its directly connected cells. The drawback is that, having a unique PM counter for all possible indirectly connected cells, no information of the geographical position of the affected cells can be provided. A second proposal is that to define in the S-RNC as many PM counters as the number of D-RNCs which is possible to connect; each time a connection is abnormally released due to that one of the connected D-RNCs is reporting back the indication of radio link failure event, the specific PM counter assigned to that D-RNC will be accordingly incremented. Even though this method allows to know in which RNC the failure event happened, yet the geographical information is still unknown. The third proposal is that to define in the S-RNC as many PM counters as the number of possible indirectly connected cells which belong to the first ring of neighbourhood. Also in this case the exact geographical position of the interested cell may not always be available, in spite of the increased number of PM counters.